雖著網際網路的進一步發展，近年來雲端運算成為一鼓新興的潮流，無論是大型的商業公司或小型的資訊服務業者，乃至於個人工作室，都乘著這鼓潮流，嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣，在開發網路應用程式或線上服務平台（以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」）的時候，也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況，例如雲端應用專案中某一部份的程式碼，因為受到第三方保密協議的拘束，所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話，那麼選擇哪些條款授權的元件，才不會造成未來應用時產生必須提供程式源碼的衝突，將是開發過程的一項重點。因此，本文將針對常見的自由開源授權條款（註一），說明相關的義務規定，據此建議雲端應用專案可以選擇哪些條款授權的元件，以避免無法提供源碼的專案產生授權義務上的衝突。 ...

軟體專利與自由開源軟體的本質有所不同（註一），因此如何將軟體專利對於自由開源軟體開發模式的衝擊降到最低，一直是自由開源領域中一個重要的議題。目前實務上所採取的應對措施有許多種，包括鼓勵重要技術的先前揭露、成立交戶授權如 Open Invention Network 這樣的組織等等，而新近修訂的自由開源軟體授權條款，也大多加入了專利授權與規劃的相關規定，因此本文選擇了數份常見且具重要影響力的自由開源軟體授權條款（註二），包括 ...

GPL 授權條款制定的目的，是希望人人都可以研究、修改與散佈程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL ...

本文上篇的文章連接頁面如右：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01 【實務上對 GPL 衍生程式可資操作的基本判別流程】 綜上所述、關於 GPL 衍生程式的判定標準，以及其授權拘束性的擴散範圍，可以歸納出三個可資操作的基本判別流程： 該軟體專案中是否內含 ...

GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 ...

零、前言 我們在寫程式的過程中，起初學習階段所寫的程式往往是練習的作品或是單純寫給自己使用的，接著愈寫愈熟練之後，我們開始會把自己寫的程式分享給同學、朋友，讓他人試試有什麼問題，一方面知道使用者還需要怎樣的功能，二方面也能使除錯的工作能做的更澈底；甚至可能後來這個程式非常叫好，大家都很有意願下載使用以及共同開發，這時就面臨到撰寫說明文件的大工程了！這時，如果我們撰寫的說明文件是搭配自由軟體一併散佈，則文件本身的著作權也必須要經過授權，才能讓使用者在重製改作時不會產生擔心侵權的後顧之憂。只是文件的授權也是 ...

最近與同事討論到一個程式釋出案的著作權標示應該如何寫才好，這個程式是修改自由軟體而來的，原本的自由軟體當然有它原有的著作權標示，將原有的軟體名稱與著作權人姓名替換之後，這個標示如下： 2006 (C) Software A, Copyright Owner A' 這是一個常見的標示：年份 + 著作權符號 + 軟體名稱 + 著作權人名稱。若 A 被 B' 修改，著作權標示也必須有相對應的修改，第一個就是軟體名稱需要改變，因為經過 ...

自己寫了一個程式，想要用自由軟體的方式來授權這個程式，卻不知道該如何做？這是不少人的疑惑。其實，就目前大部分的自由軟體授權條款的規定來看，並沒有一定必須遵守的宣告方式，所以重點就在於：要讓他人可以清楚明確地知道這個程式是採用自由軟體方式來授權。   一、條款全文 將授權條款附在程式中一起散布，這是最簡單的方法。像採用 BSD、MIT 這一類簡短條款授權的話，就可以將條款全文附在每一個原始碼檔案的一開始，這樣利用其中任意一個原始碼檔案的人，也可以明確地知道這些原始碼是採用 ...

最近工作上處理到一件程式釋出案，覺得十分有趣，所以在這邊跟大家分享一下，不過因為整件釋出案的釋出方式尚未定稿，所以我會隱去真名實姓與許多片段，僅就必要的資訊加以描述。 整件釋出案的最終的目的是：「為自己寫的程式碼挑選一份合適的自由／開放源碼條款來授權」，但這個程式有利用到他人的自由／開放源碼程式碼（他人程式碼），所以就要看這些他人程式碼的授權內容為何，是否會對挑選自己程式碼的授權條款有所限制。這些他人程式的授權條款如下（註一）： ...

每一個自由/開放源碼專案在釋出時，都會遭遇到一個問題：應該為自己的程式選擇那一個授權條款？因為著作權人對於未來運用程式構想不盡相同，所以這是一個可大可小的問題。 若著作權人相當認同自由/開放源碼理念，希望可以提供他人最大的機會取得原始碼，那麼 GPL 類（註一）的授權條款就很適合，因為 GPL 類條款承襲 copyleft 精神（註二）， 讓取得程式之人也有取得原始碼的權利，即使程式被修改後也一樣。若是不拘原始碼是否一定可以被取得，而僅希望程式可以被他人廣泛地再利用，則可以選擇 ...